|
Тестирование Как уже не раз отмечалось, тестирование игры - это один из ключевых этапов разработки, требующий самого пристального внимания. Тогда почему в компьютерных играх так много ошибок? Почему стал привычным выпуск многочисленных патчей (исправлений) к уже вышедшим играм? В чем здесь дело - разработчики обленились? Считают, что практика пострелизных патчей эффективней тщательного тестирования еще не выпущенной игры? Тому есть ряд объективных причин. Во-первых (и это самое главное), компьютерные игры - это далеко не то же самое, что игры для приставок, когда все конечные потребители используют одно и то же оборудование (приставки PlayStation, Dreamcast и Nintendo 64 абсолютно одинаковы, что в Америке, что в Европе, что в Азии, за исключением разве что используемого ПО). А теперь попробуйте найти хотя бы двух пользователей, чьи ПК будут обладать одинаковой конфигурацией! Возможны тысячи самых разнообразных сочетаний программного и аппаратного обеспечения, поэтому задача достижения корректной работы игровой программы для каждого из таких сочетаний превращается в сложнейшую головоломку, а разработка игр для ПК начинает напоминать стрельбу по движущейся мишени. Во-вторых, выпуск компьютерных игр - это в первую очередь бизнес. Если игра не поступит вовремя в продажу, производитель потеряет деньги (особенно в течение прибыльных сезонов продаж), а так как многие крупные издатели компьютерных игр являются открытыми акционерными обществами, то они обязаны публиковать ежеквартальные финансовые отчеты. Один неудачный квартал может самым неблагоприятным образом повлиять на курс акций компании. Под давлением обязательств перед прессой и торговой сетью многие фирмы выпускают откровенно «сырые» продукты, сопровождая их комментариями вроде «исправления будут доступны в Интернете через пару недель». В итоге, пользователь, разочаровавшийся в продукции компании, перестает быть ее покупателем... По данным Мэтта Гравета (Matt Gravett), координатора известнейшей исследовательской службы PC Data, отвечающего за информацию по продажам видео- и компьютерных игр, каждый год за один только декабрь консольных игр реализуется свыше 30%, а игр для ПК - свыше 25% от годового объема продаж. Вот почему многие издательства выпускают свои игры преждевременно, лишь бы только попасть на полки магазинов в предрождественские дни. Разнообразные подходы к тестированию игр на наличие ошибок и совместимость можно разбить на две группы. • Бета-тестирование (тестирование предварительной версии) начинается, когда игра находится на стадии между поздней альфа- и ранней бета-версией, отсюда и название. Этот весьма трудоемкий этап в создании игры «на совести» собственно разработчика или издателя. В каждой компании его проводят по-разному. В ряде случаев бета-тестирование доверяют добровольцам из числа пользователей. • Контроль качества (Quality Assurance, QA) осуществляется специалистами по тестированию, не имеющими отношения к разработке игры и не являющимися игроками. Он проводится по спецификации выпуска продукта, определяющей поддерживаемые конфигурации аппаратного и программного обеспечения, и завершает собой производственной цикл создания игры. Перед выпуском игры анализируются также присланные сообщения об ошибках и другие замечания. После выхода игры в свет группа технической поддержки рассматривает жалобы пользователей, а разработчики внимательно изучают группы новостей и веб-форумы. В результате составляется и систематизируется список замечаний, на базе которого выпускается первый патч. В ряде случаев исправления полностью оправданы - например при появлении новой видео- или аудиоплаты уже после выпуска игры. В этой главе обсуждаются вопросы тестирования игр в процессе их создания. Советами по этому поводу делятся специалисты таких уважаемых компаний, как Acclaim Entertainment, Electronic Arts, Psygnosis, Interplay, Firaxis, Origin Systems, Humongous Entertainment и Blue Byte. Кэрол Караккиоло (Carol Caracciolo), Acclaim Entertainment Кэрол Караккиоло отвечает за контроль качества в отделении компании Acclaim Entertainment, располагающемся в городе Глен Коув (штат Нью-Йорк, США). Она участвовала в разработке множества игр, в том числе Mortal Kombat II, Turok: Dinosaur Hunter, Quarterback Club, All-Star Baseball, NBA Jam, WWF: Raw, WWF: Warzone, Alien Trilogy, Revolution X. В ее подчинении находятся около семидесяти пяти человек, обеспечивающих двухсменную непрерывную работу в течение семи дней в неделю. По мнению Кэрол, тестируя игры, следует придерживаться трех важнейших правил: а) не отлынивайте от тщательного описания ошибок и не позволяйте никому отговорить вас от занесения ошибки в базу данных; б) прежде чем зафиксировать ошибку, тщательно исследуйте проблему; в) проверяйте, проверяйте и еще раз проверяйте. Насколько сложен подбор сотрудников, занятых поиском ошибок в программном обеспечении? Трудно ли найти игроков, согласных и способных выступить тестерами? Ответ Кэрол: Найти желающих не проблема. Страсть к играм заставляет этих людей проявлять инициативу - они сами найдут вас. Трудность заключается в том, чтобы выбрать из огромного числа претендентов тех немногих, кто любит игры настолько, что готов проводить за тестированием по восемь часов в день, пять дней в неделю в течение четырех-шести месяцев. Далее Кэрол поделилась соображениями о том, сколько людей необходимо задействовать на этапе контроля качества и как она обеспечивает выявление и документирование ошибок. Во время пиковой загрузки оптимальным является сочетание временных и постоянных сотрудников в отношении два к одному. Когда продукты идут в производство один за другим, к двадцати постоянным сотрудникам я добавляю от тридцати до сорока временных. Контроль качества с помощью столь внушительной группы - дело не легкое. Однако у нас работают опытные руководители и ведущие технические сотрудники, буквально опекающие временно привлеченный персонал, а также, если это необходимо, участвующие в его обучении в период испытательного срока. За годы работы мы опробовали и внедрили в свой производственный процесс все самое лучшее из известных методик тестирования. Мы составляем подробные планы, осуществляем детальный анализ ошибок и их регистрацию с помощью специально предназначенных для этого программных средств. Чтобы обеспечить выполнение графика тестирования, мы постоянно ведем выборочную проверку таблиц ошибок и баз данных, полученных от каждого тестера. Все сотрудники в обязательном порядке посещают занятия по «переподготовке», чтобы быть в курсе всех новостей и изменений. В заключение, Кэрол Караккиоло попросили подытожить сказанное каким-нибудь примером. Последней игрой, которая заставила нас внести изменения в методику тестирования, была Bust-A-Move. Поначалу она выглядела совершенно безобидно, и мы были уверены, что игра с легкостью пройдет тестирование. Однако количество разветвлений ее сюжета оказалось почти бесконечным. Это вынудило нас устроить тщательный разбор всего процесса тестирования и составить его обширный предварительный план. Такой план необходим не только для контроля за ходом тестирования на этапе исполнения, он просто неоценим для планирования потребностей в персонале и оборудовании. Шон Хауз (Sean House), Electronic Arts Когда Шона Хауза, помощника продюсера отдела ЕА Sports, спросили, отличается ли тестирование игр в его компании от того, что принято у других производителей, он ответил, что да, и привел следующие веские причины: Тестировать спортивные игры в конце их разработки (в последние три месяца или около того) - это единственно возможный способ. Причина в том, что график разработки, как правило, оказывается крайне напряженным (на весь проект отводится всего один год). Программисты обычно лезут из кожи вон, пытаясь осуществить все, что было намечено, и на ошибки, которые можно было бы выявить в процессе разработки, просто не обращают внимания. Время на отладку у них появляется только по завершении текущего этапа разработки (или его части).
Шон признал, что такую ситуацию нельзя считать нормальной, и заметил, что в идеале следует постепенно увеличивать объемы тестирования по мере приближения проекта к финалу. Это даст тестерам возможность «гонять» игру в течение нескольких месяцев, даже если при этом приходится постоянно переключаться с одной ее части на другую. Тестеры, к слову, не против таких переключений - чем меньше изматывающего однообразия, тем продуктивнее их работа. Процесс отладки при этом также становится ощутимо более действенным, ведь многие области игры взаимосвязаны. Ошибка в одном месте может вызвать несколько промахов в другом, поэтому тщательное «вылизывание» каждого фрагмента облегчает отладку последующих. Далее Шон объяснил, как в ЕА Sports понимают разницу между бета-тестированием и контролем качества: У нас контроль качества (QA) осуществляется группой штатных сотрудников, получающих продукт, после того как он прошел через отдел производственного тестирования. Группа контроля качества - последняя линия обороны перед выпуском игры. К этому моменту все ошибки в игре должны быть полностью устранены. Задача группы QA - поставить себя на место пользователя и высказать свое мнение о функциональных возможностях игры, выявляя при этом незамеченные ранее ошибки. Кроме того, группа занимается обеспечением юридической чистоты продукта (появляющиеся на экране уведомления, приведенные в лицензионных соглашениях сведения и т.п. - ее работа). Обычно это те же самые люди, которые потом будут осуществлять техническую поддержку, так что они напрямую заинтересованы в качестве продукта: больше пропущенных ошибок - сильнее головная боль после выпуска игры. Бета-тестирование - это предварительный выпуск бета-версии игры (почти законченной, с очень небольшим количеством ошибок в продукте) и передача его либо всем желающим, либо специально отобранной группе. Эти люди проходят игру и сообщают об обнаруженных в ней ошибках. Резкое увеличение в очень короткое время круга лиц, видевших продукт, является кардинальным средством быстро устранить последние оставшиеся ошибки. Во время моей работы в ЕА Sports подобное бета-тестирование не проводилось ни для одной игры. Мы предпочитаем обычное производственное тестирование, начинающееся, как правило, за месяц до появления альфа-версии (все главные функции игры уже реализованы, хотя и с ошибками) и продолжающееся до самого выпуска игры. По-моему, при создании любого программного продукта одинаково важны и производственное тестирование, и контроль качества. Отделы, отвечающие за эти этапы, прекрасно дополняют друг друга. Часто, особенно к концу проекта, тестеры изматываются (работать по шестнадцать часов в день очень тяжело), поэтому легко могут пропустить очевидные ошибки. И тут в дело вступает свежая группа контроля качества. Ее сила также в том, что она рассматривает игру с точки зрения конечного пользователя (не имеющего никакого отношения к разработке), а значит, вполне способна составить объективное представление о продукте. Шон Хауз припоминает яркий пример из своего профессионального прошлого, доказывающий важность обоих видов тестирования. Это настоящий анекдот: Пять лет назад я работал тестером в компании Media Vision во Фремонте (Калифорния). Велось тестирование сразу нескольких мультимедийных продуктов. Одну из игр надо было закончить к 26 декабря. Работа была почти сделана к 23-му, ибо никому из нас не хотелось сидеть на службе в Рождество, поэтому мы провели за ней все 23-е, закончив тестирование в шесть утра 24 декабря. Нечего и говорить, что мы здорово устали, а значит, были не особенно внимательны. Игра должна была распространяться на дискете. Окончательная версия была готова в три часа утра 25-го, и мне было поручено сделать ее мастер-копию. Оставалось лишь проверить, устранена ли последняя ошибка, что я быстренько и сделал, прежде чем раздать дискеты тестерам. При инсталляции требовалось ввести имя и название организации, и я, просто ради смеха, набил «Coitus Interruptus». Все без проблем установилось, ошибка была действительно исправлена, дискету можно было запускать в тираж. Погоняв игру еще немного, я передал свою копию руководителю группы. Отдела контроля качества у нас не было, поэтому он просто отправил ее в производство. Работа закончена! Мы были счастливы. Недели через три, когда игра уже вовсю продавалась, начали поступать телефонные звонки. Пользователи в один голос жаловались, что не могут зарегистрировать игру, так как в графе «имя» стоит «Coitus Interruptus»... Нечего и говорить, что все дискеты были тут же отозваны. Это обошлось компании в 225 тысяч долларов. Основную ответственность понес мой начальник. Я, конечно, чувствовал себя просто ужасно, но зато получил хороший урок. Последняя линия обороны - полезная штука. Отдел контроля качества, будь он у нас, непременно отловил бы мой промах. Кроме того, моему начальнику, видимо, все же стоило хотя бы разок просмотреть игру с финальной дискеты. Но это уже другая история... В заключение Шон Хауз сказал, что важность производственного тестирования, как и контроля качества, подтверждается множеством других примеров, и он не может представить себе процесс создания игры без этих этапов. Марк Грин (Mark Green), Psygnosis Марк Грин, с которым мы беседовали в филиале компании Psygnosis в Великобритании, рассказал о своем подходе к тестированию и хронологической последовательности действий, без которых Psygnosis не выпускает ни одной игры. Заодно он объяснил, как, когда и почему эти действия должны выполняться. Заключительная фаза проекта, последние шесть месяцев работы - это время, когда становится ясно, чего ты стоишь. Именно этот этап разработки либо рождает игру, либо заканчивается провалом. Не имеет никакого значения, что до этого у вас все было в полном порядке: любое упущение на этом этапе чревато самыми серьезными последствиями. Во-первых, следует быть достаточно сообразительным, чтобы поддерживать контакт с отделом контроля качества на протяжении всего проекта. Как правило, сотрудники отдела контроля качества - это самая тесная связь с игровым миром, какая у вас только есть. Все они - упертые игроки, и если что-то не в порядке, они непременно сообщат вам об этом. Чувствую, вы сейчас скажете: «Я знаю, что такое хорошая игра. Я и сам вижу, что в игре плохо. Зачем мне рассказывать о том, что я и так знаю?» Увы, проблема в том, что разработчики так тесно связаны со своим детищем, что попросту не видят за деревьями леса. Разработчики делятся на две группы: одна половина думает, что их игра - нечто фантастическое, хотя на самом деле это дерьмо; другая уверена, что их игра никуда не годится, хотя она вполне удачна. Третьего не дано - разработчик не может быть беспристрастным. Сейчас мы все больше и больше привлекаем к сотрудничеству обозревателей из журналов, людей, несомненно, более объективных, чтобы они изучили игру до ее выпуска. В результате мы получаем замечательные по своему профессионализму отзывы. Разумное применение таких приемов позволяет в итоге получить не просто хорошую, а блестящую игру. Спустя шесть месяцев после начала разработки игра переходит в стадию, которую мы называем альфа-версией. К этому моменту в продукте должно быть реализовано все, что вы хотели бы в нем видеть. При этом игра не обязана хорошо смотреться и идеально работать. Важно другое: вы наконец-то говорите «нет» всем добавлениям и новым возможностям. Ваша работа над альфа-версией (как и работа отдела контроля качества) заключается в том, чтобы проверить игру и добиться того, чтобы она неплохо выглядела, нормально игралась и перестала виснуть. Обычно это занимает около шести недель. Следующий этап - бета-версия, или предварительная версия игры. И тут-то начинается самое трудное - Охота За Ошибками! Как правило, кое-кто (не будем говорить кто именно, хотя речь идет об этих проклятых продюсерах, чтоб им пусто было!) пытается тщательно спланировать, сколько это может отнять времени, хотя в любом случае все сводится к вопросу «сколько еще веревочке виться?»... Если у вас действительно хорошие программисты, проблем будет не так много; в противном случае неизбежны самые тяжелые времена. К тому же, как назло, именно в этот момент отделу распространения и маркетинга обычно взбредает в голову отправить разработчиков на какую-нибудь презентацию - поболтать с журналистами (короче говоря, оторвать их от работы над игрой). Обычно бета-тестирование длится около четырех недель. Последняя стадия - передача изделия в производство. Если разработка ведется не для ПК, а для игровой приставки, это делается в два этапа: внутренний и внешний. Сначала ваш собственный отдел контроля качества завершает последнюю, самую тщательную проверку и дает вам возможность устранить недоработки. Затем вы отправляете игру изготовителю. Там потратят еще пару недель на проверку, не только на отсутствие ошибок, но и на соответствие игры внутренним стандартам компании. Найденные ошибки - это автоматическое возвращение игры разработчику и повторное прохождение всей процедуры. Судя по моему опыту, каждая попытка занимает в среднем две недели, так что неудача может здорово удлинить этот этап. Наконец, дело доходит до мастер-копии (или «золота»). Вы можете вздохнуть с облегчением и снова окунуться в общение с внешним миром, которым вы жертвовали два последних года, работая над проектом. Месяц спустя полки магазинов заполняются вашей игрой, и вы молитесь, чтобы она заняла в хит-парадах первое место. Одним из самых последних проектов, в котором Марк Грин принимал участие в качестве автора и продюсера, была игра Global Domination. Чип Бамгарднер (Chip Bumgardner), Interplay Productions Чип Бамгарднер - продюсер множества игр. Упомянем лишь некоторые из них: Chessmates, Lost Vikings 2, Earth 2140, Dragon Dice, Max 2 и серия Caesar's Palace. Кроме того, он помогал разрабатывать уровни для нашумевшей игры Redneck Rampage. Чип сказал, что тестирование игры начинается куда раньше, чем можно себе представить. На самом деле, команда разработчиков тестирует игру в течение всего времени ее создания. Так гораздо проще находить ошибки, а заодно и настраивать игру. Чип признается, что большая часть тестирования проводится в течение последних недель (или месяцев) работы над проектом, чтобы удостовериться, что все функционирует должным образом. Крис Тэйлор (Chris Taylor), Interplay Productions Крис Тэйлор, бывший ведущий дизайнер Fallout и Stonekeep и дизайнер-консультант Мах 2, говорит, что тестирование игры состоит из трех основных этапов: производственного тестирования, бета-тестирования и контроля качества. Разработчики должны постоянно играть в игру и тем самым тестировать ее. Ведь они - единственные, кто по-настоящему знает игру и имеет представление о том, как она должна работать. Бета-тестирование - это мнение об игре посторонних. Они помогут найти узкие места и проверить продукт на совместимость. Что касается контроля качества - это просто более формализованное бета-тестирование с максимально подробным описанием ошибок и тщательной проверкой совместимости. Иногда группа контроля качества и в самом деле может помочь при разработке игр, а иногда там слишком заняты поиском ошибок, чтобы оказать реальную помощь. Я считаю, что требования к тестированию и подход к организации этого процесса сильно зависят от компании и продукта.
Вольфганг Валк (Wolfgang Walk), Blue Byte Вольфганг Валк работает в студии Blue Byte Software в Германии. Он был руководителем проекта Incubation. Его мнение о предмете обсуждения, по-видимому, совпадает с мнением других разработчиков: Тестирование - наше все. Только оно может обнаружить все ошибки и недоработки, которые неизбежны на ранней стадии проекта, когда игра существует скорее в вашей голове и кое в каких документах, но пощупать это руками еще нельзя. Тестирование подскажет вам, интересна ли игра, что необходимо изменить, чтобы исчезли скучные, вгоняющие в тоску фрагменты, которые иногда появляются в процессе разработки. А еще, оно, конечно, поможет найти ошибки. Правда, стоит помнить, что имей вы хоть сотню тестеров, все равно пятьдесят тысяч пользователей в первый же день после покупки найдут еще море ошибок. Все это дело случая. Игры сегодня столь сложны, что полностью избежать ошибок почти невозможно. Увы, журналисты и пользователи об этом часто забывают. «Само собой, - заключил Вольфганг, - это не касается продуктов с грубыми ошибками, которые проявляются после двух минут игры на среднем уровне». Ричард Гэрриот (Richard Garriott), I Origin Systems Единственный и неповторимый Ричард «Лорд Бритиш» Гэрриот, автор идеи легендарной серии игр Ultima компании Origin Systems, рассказал, как много сил они затрачивают на тестирование игр, особенно сетевых, приведя в качестве примера Ultima Online. «Популярная сетевая игра должна разрабатываться как следует с самого начала; у вас должен быть отменный исходный текст. Если исходный текст хорош, группа контроля качества достойно выполнит свою работу». К несчастью, нет иного способа тщательно протестировать принципиально новую игру вроде Ultima Online, рассчитанную на одновременное участие массы игроков, кроме как в процессе самой игры. Это могут засвидетельствовать несчастные, которым удалось вступить в игру первыми, сразу после ее выпуска. Впрочем, вскоре к игре были добавлены многочисленные дополнительные серверы по всему миру, а в Техасе вопросами снижения трафика занялась группа специально выделенных инженеров.
Ричард Гэрриот рассказывает, что, тестируя игры внутри компании, они пытаются играть так, как играл бы человек, который видит игру первый раз в жизни. Кроме того, в обязательную программу тестирования входит проверка всех основных функций игры и их комбинаций, что часто превращается в довольно утомительную задачу. Он поясняет: Предположим, в игре есть пятьдесят заклинаний. При этом тестер должен проверить действие всех заклинаний и всех их комбинаций на всех типах монстров, вспомогательных персонажах и предметах для каждого уровня. Это огромный объем работы, у нас половина офиса завалена томами с описаниями программ тестирования! И все это надо проделать с каждой версией игры, с каждой ее «сборкой». Ну а в заключение, Лорд Бритиш напомнил нам, что все это должно быть проделано для максимального количества компьютерных конфигураций от максимального количества производителей. Весело, правда? Сид Мейер (Sid Meier), Firaxis Games Мэтр Мейер уже не раз появлялся на страницах этой книги, чтобы поделиться своими мыслями о разработке игр. Говоря о том, как следует тестировать игры, он проявил солидарность с мнением Ричарда Гэрриота. Прежде всего - проверка на наличие ошибок, которая должна производиться как можно большим количеством людей и на самых разнообразных компьютерах. Важна также методика воспроизведения и записи ошибки. Ошибка не стоит потраченного на нее времени до тех пор, пока она не будет тщательно описана и не будут выявлены условия ее воспроизведения. Чтобы облегчить воспроизведение ошибки, Сид Мейер использует самые разные способы, например встроенную в игру функцию автосохранения, фиксирующую ваше местоположение каждые десять секунд (или около того). Это позволяет воспроизвести ошибку, просто загрузив игру с нужного места. Еще одна важная вещь, которая требует проверки, - выяснение того, не является ли игра слишком легкой или сложной. К сожалению, разработчики здесь не помощники: они очень близки к проекту, чтобы иметь объективный взгляд на игру. Следовательно, надо предложить игру другим людям - чтобы поглядеть, что они будут делать, выяснить, где застрянут. Наконец, Сид Мейер заметил, что наиболее важны первые полчаса игры новичка, когда решается вопрос, захочет ли он продолжить игру. Рон Гилберт (Ron Gilbert), Humongous Entertainment Всемогущий Рон Гилберт отвечал за разработку многих бестселлеров компаний LucasArts, Humongous Entertainment и Cavedog Entertainment. Когда мы заговорили с ним о тестировании, Рон напомнил, что в этом плане его любимые квесты стоят особняком. Что он имеет в виду? Тестирование квестов - это в основном поиск ошибок, в отличие от игр других жанров. Вам не надо беспокоиться о сбалансированности игры, как в стратегиях, не надо тестировать многопользовательский режим. Квесты - это линейное развитие сюжета, неизменное расположение предметов, относительная игровая стабильность. Что касается игр вроде Total Annihilation: Kingdoms, то, когда дело доходит до тестирования, в них играют целыми днями напролет, чтобы убедиться, что все юниты настроены как следует. А после схватки по сети разработчики собираются вместе, чтобы обсудить свои наблюдения. Это что, такой обычай? Это единственно верный подход. Тестеры, конечно, опишут ошибки в соответствующих формах и тщательно их задокументируют, но когда вы проверяете, как играется в эту игру, ничто не может заменить живое обсуждение. Рон привел пример нестыковки в игре, найденной при тестировании. «Если лучники создаются слишком быстро и вы излишне легко захватываете вражескую базу, мы увеличиваем время, необходимое на их создание, и снова переигрываем это место». И так до тех пор, пока игра не станет должным образом сбалансированной. Напоследок Рон сообщил, что в Humongous и в родственной ей Cavedog внешнее тестирование не проводится, потому что весь контроль качества осуществляется соответствующими отделами внутри этих компаний. «Впрочем, - философски заметил Рон, - все течет, все изменяется...»
|